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BACKGROUND OF THE INVENTION 

The invention relates to a ring network, and 
particularly to a system and an implementation 
technology for actualizing MAC (media access control) 
bridging on RPR (Resilient Packet Ring) protocol 
mainly defined by IEEE802.17. 

The RPR is a network protocol technology mainly 
aiming at being provided a network for connecting 
between cities, such as MAN/WAN (Metropolitan Area 
Network/Wide Area Network) . An examination of the 
RPR is underway in order to establish a draft at the 
IEEE802.17 Committee. As of September in 2002, Draft 
version 1.0 (tentative specifications) as first 
standard specifications were released, at which stage 
they were approved at the meeting at the end of 
September, and the final specifications are scheduled 
to be determined in March in 2003 through necessary 
modifications thereafter. The RPR is based on SRP 
(Spatial Reuse Protocol) released by Cisco Corp. and 
has the following features. 

1. The RPR supports a bidirectional dual ring network. 

2 . The RPR supports a MAC layer in layer 2 . 

3. An effective utility rate of a using bandwidth is 
high. 

4. The RPR supports Plug & Play. 
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5. A protection switching time is sub-50 ms . 

Note that the SRP is described in, for instance, 
a Patent document 1 . 

The following points in addition to the above- 
mentioned are characteristic of the RPR. 

1. There are three priority classes, and it is easy 
to implement QoS (Quality of Service) control on the 
high-order layer. 

2. A protection switching system is a steering 
protection (which is a system for switching a route 
having a failure to another route of a reversed 
direction along the ring, and a wrapping protection 
(which is a system for turning the route having a 
failure back in the reversed direction along the ring 
just anterior to a failure point) is an option. 

3. The RPR is a system that is limited to the MAC 
layer in the regulations and does not depend on the 
lowest-order layer (the physical layer) . 

The RPR is a novel MAC layer protocol and 
terminates the MAC frame. Accordingly, a basic idea 
has hitherto been such that a device (a RPR device) 
implementing the protocol should be a device (which 
is router, gateway, and the like) executing a layer 
process higher than this. At the recent IEEE 
25 meetings, however, an examination for defining a 

forwarding method so that the RPR device can function 
as a device (which is a so-called bridge) capable of 



transparently forwarding the MAC frame, is underway. 

With respect to the forwarding method, a good 
deal of problems and methods for solutions thereof 
are presented, and finally a forwarding method based 
on IEEE802.1D was proposed. The proposed method also 
however, has a problem, and, in the present, 
standards of the forwarding method are not yet taken 
shape . 

For describing the technology according to the • 
invention of the present application, the following 
terms will at first be defined. 

(1) MAC frame: the ^^MAC frame'' is a frame 
having a MAC header. Herein, this indicates a frame 
of the Ethernet (registered trademark) defined in 
1EEE802.3 and a frame having a RPR MAC header defined 
in IEEE802.17. Especially in the case of 
distinguishing therebetween, there are called an 
^^EMAC frame" and a ^^RMAC frame", respectively. FIG. 

17 shows formats of the EMAC frame and the RMAC frame, 

(2) Node: the ''node" is a device for 
actualizing the RPR protocol. Each node exists on 
bidirectional dual rings (two counter-rotating 
ringlets) . In the specification, the node might be 
called a ''RPR node" and also called a "RPR device". 

(3) Station: the "station" is a device that 
terminates the MAC frame. The station receives the 
MAC frame and transfers a data field thereof to a 
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high-order layer. Further, the station assembles the 
MAC frame including data from the high-order layer 
and transmits it. When the station receives the MAC 
frame, if the MAC frame has an error, or a 
destination MAC address (MAC DA) of the MAC frame is 
not coincident with a MAC address of the station 
itself, the MAC frame is basically discarded. In 
case a receipt frame is a RMAC frame, however, the 
RMAC frame is made to pass through on the side 
opposite to the side of having received it. In a 
case where a node (a RPR node) that performs 
processing of the RPR protocol has functions as the 
station, the node is called a "station node". 

(4) Bridge: the "bridge" is a device that 
forwards the MAC frame as far as any error does not 
occur.. Normally, the bridge copies and distributes 
the MAC frame received at one of physical ports to 
all other physical ports. Further, the bridge has a 
MAC address learning function, and creates and keeps 
a table (called "a port-to-MAC address mapping table" 
or «MAC learn table") from MAC DA/SA (source address) 
of MAC frames to be forwarded. The table shows a 
physical port to which a device indicated by the 
source/destination addresses of the MAC frame is 
connected. The bridge checks MAC DA/SA of each 
received MAC frame. If the MAC SA is not registered 
in the table, the bridge registers the MAC SA with an 
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identifier of a physical port (e.g., port number) 
received the MAC frame to the table. Further, if the 
MAC DA is already registered in the table, the bridge 
forwards the MAC frame to only a physical port 
5 corresponding to the MAC DA by referring the table. 
An extra load is thereby prevented from being applied 
to other ports. In a case where the node (the RPR 
node) performing the processing of the RPR protocol 
has the bridge function, this node is called a 
10 "bridge node". 

Next, a method of transmitting and receiving 
the RMAC frame between the stations, which is 
tentatively defined in IEEE802.17, will be at first 
explained as a prior art (see, for instance, Non- 
15 Patent document 1) . 

FIG. 18 shows one example of a RPR network. FIG. 
18 shows a plurality of nodes SA-SL as station nodes 
each having the station function. The nodes SA-SL 
are sequentially connected in a ring-shape in a state 
20 (sequence) illustrated in FIG. 18 via bidirectional 
communication lines (two counter-rotating ringlets) . 
Normally, an optical fiber is used as communication 
line. Herein, for the sake of explanation, the RPR 
network is defined as follows. 
25 <1> MAC addresses of the respective nodes are : 
SA: MSA, SB: MSB, ... SL: MSL 
<2> Clockwise connecting sequence (outer ringlet) is: 
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SA SB SC ... SL ^ SA 
<3> coun,. ^^^^^^^^^^ ^^^^^^^^ 

SA SL^ SK ... SB SA 

IntheHPR, it is define, that a node. When 
5 receives a MAC fr;,mo ^ 

"AC frane. performs processes as below. 
\^) An error chpov o 
-CS/HEC Of the MAC f " °" 

the MAC f ' ^^^^^ - - error, 

the MAC frame is discarded. 

(B) In case there i « r,^ 
0 the MAC f °« Of 

MAC fra„,e is checked, if the MAC DA is . ■ 

"-h a MAC address of the node itself t ZT^" 

r T"^^ ' --'^ ther e f s 

transferred onto the hi,h-order layer. 

(C) When the MAC address 
the node itself th . " ^ 

SA is . " If the MAC 

SA .s coincident with the node's MAC addr 

frame is discarded. "'^ 

(D) In case it i«5 r,r,i- 

-^i- J-s not coincidf:»nt- 

TTT /T- ^J<--Laent, a value of 
TTL (Time to Live) of the MAP 

the TTT . ""^ checked, if 

the TTL value is under 1 (not TTI i ^ 

is discarded. (not TTL = i) , the MAC frame " 

(E) When the TTL value is l or more (TTL - i • 
established) one • ~ 

one (1) IS subtracted from th« 
TTL value ^ Present 

vdiue, and the MAC -fr-a.^^ • 

i^AC frame is reassembled 
(concretely, the HEC and FCS ar. 

i^cs are recalculated) and 

transmitted to a next 

,.11,, neighboring node (which is 

called "pass") . 
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Accordingly, the node SA shown in FIG. 18 in 
the case of transmitting a frame to the node SD 
assembles a RMAC frame as shown in FIG. 19. 

Normally, each node ,the node SA) transmits the 
5 frame onto a ringlet of a direction <which is called 
"near <short, direction", that the number of nodes 
forwarding the frame is small. Therefore, the node 
transmits the frame to the outer ringlet 
The frame reaches at first the node SB. The node SB 
-LU as the MAC DA of th^:^ rr^=.rr.^ • 

« ol the frame is not coincident with the 

«AC address of the node SB itself, lets the frame 
pass through , to be concrete, transmits the frame to 
the neighboring node SC corresponding to the next 
node, . At this time, one is subtracted from the TTL 
value Of the frame. The node SC executes the same 
process as the node SB does, and the frame arrives at 

^3 coincident with the MAC address of the node SD 
captures the frame inside the node SO, and transfers 
• u the data field of the. fr=„„ 

a ol the frame onto the high-order layer 
thus completing the process. 

For executing the process described above, each 
node is required to specifically grasp the nu„0.er of 
forwarding nodes, each of which exists between a 
= source node .node itself, and the destination node 
With respect to each direction of ringlet (outer and 
xnner ringlets,, m the RPR protocol, for achieving 
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the object, a control packet that is called a 
topology discovery packet for grasping a topology of 
the ring (each ringlet) , i. transferred and received 
between the RPR nodes. The topology discovery packet 
. includes the MAC addresses, as pieces of information 
of the source node itself and the neighboring nodes 
thereof. Each of the nodes receiving the topology 
drsccvery packet adds a piece of self-inf creation ,a 
MAC address of the node itself, and sends it to the 
neighboring node. These processes are executed each 
node. Eventually all the nodes are thereby able to 
know the MAC addresses of all other nodes and the 
number of the forwarding nodes (which is precisely a 
value of TTL needed for the frame transmission, 
Each node retains them as a topology map table. By 
way of an example. FIG. 2 0 (Table 1, shows the 
topology map table retained on the node SA 
illustrated in FIG. 18. Note that the topology 
discovery packet is. when in an initial setting in 
addition to when adding and deleting the nodes 
periodically transmitted and received between the 
respective nodes, whereby updated information of the 
network can be kept at all times. 

Further, in case of failures occurred in the 
node or on the communication line between the nodes 
each node, when detects the failures, sends a control 
packet called a protection packet to all other nodes 
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Each of the nodes is thereby notified of a change of 
the topology. The change of the topology is 
immediately reflected in the topology map table. By 
way of an example, FIG. 21 (Table 2) shows a change 
5 of the topology map table when a failure occurred on 
the communication line for transmitting the frame the 
node SD from the node SC to the node SD illustrated 
in FIG. 18. Thus, a state of the topology is 
reflected in the topology map table. Thereby, it is 
10 indicated that the node SA cannot perform 

communications, about each node further than the node 
SD, by using the outer route. Therefore, the node SA 
can actually judge that using the inner route to 
perform communications to each node further than the 
15 node SD. Such a technology is called steering and is 
one of the principal technologies of the RPR. 

Now, in the case of applying the RPR to a 
normal network, other than the nodes on the rings, a 
variety of networks such as the Ethernet, etc. are 
20 normally connected, and it is required that the 
communications between stations (of f-the-ring 
stations) , each of which is located in the outside of 
the rings and is accommodated to one of nodes (on- 
the-ring nodes) on the rings, be possible. 
25 Originally, the RPR is based on an assumption 

that the frame is routed between the off-the-ring 
stations via the high-order layer. Namely, the MAC 
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frame, which has been received by the node on the 
ring and comes from the off-the-ring station, is 
temporarily designated in its forwarding destination 
(other on-the-ring node) by the high-order layer and 
is then transmitted as a frame of a RPR MAC layer 
onto the ring. Then, the frame is received by a 
different node on the ring, then also designated in 
its forwarding destination (an off-the-ring station) 
by the high-order layer, and transmitted to a 
destination station after becoming a frame of an 
outside protocol. This forwarding procedure 
indicates that the node on the ring must invariably 
be a router. In the case of the same layer protocol 
as the RPR where the frame dealt with by the off-the- 
ring station is an Ethernet frame, etc., however, 
there is a large load in terms of a cost and a speed. 

The IEEE802.17 Committee, for solving the above 
problem, assumes a MAC bridging system for giving a 
bridge function of forwarding the MAC frame with no 
intermediary of the high-order layer, and is going to 
incorporate a function of making the RPR node 
function as a bridge into the rules. At the present, 
a prospective rule on the occasion of actualizing the 
function may be a transparent bridge system, defined 
in IEEE802.1D, and the rules of IEEE802.17 will be 
settled in the direction (refer to, e.g., Non-Patent 
documents, 2, 3, 4, 5) . 
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The transparent bridge system has, however, 
some problems that will be given as follows. The 
IEEE802.17 Committee also pointed out the problem, 
and, in the present situation, tangible standard 
rules of the bridge function are not yet seen. 

A bridge device for executing MAC bridging, in 
the case of being installed as, for instance, a 
bridge node on the RPR network defined in IEEE802.17 
as shown in FIG. 22, must be capable of the following 
communications (refer to, e.g., Non-Patent document 
6) . 

1) SX-BJ-BD-SY communications (bidirectional) 

2) SX-BJ-SA communications (bidirectional) 

3) SA-SG communications (bidirectional, bridge pass) 

For enabling all these communications, a 
transparent bridge system of IEEE802.1D was proposed 
at the IEEE802.17 Committee, m the case of applying 
the system directly to the node in the RPR network, 

the bridge node execn-t-e^.; -Fr-^rr,^ 

^ vjv-ic executes trame processing (a 

transparent translation) shown in FIG. 23. 

In FIG. 23, the on-the-ring bridge node 
executing the framing processing learns information 
about which on-the-ring bridge a MAC address off the 
ring where the communications are performed is linked 
to, and sorts out it into a table. The 

communications 1) through 3) can be thereby performed. 
The transparent bridge system has, however, the 
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following problems pointed out by the IEEE802.17 
Committee (refer to, e.g., Non-Patent document 7). 

A relationship between the MAC address of the 
bridge node and the MAC address of the off-the-ring 
5 device connected to the bridge node, remains 

unlearned. Therefore, in the bridge node through 
Which the frame addressed to the off-the-ring device 
IS passed, the frame is copied addressed to the 
network connected to the bridge nodes (which is 

10 called bloodina) anri -t-h^^^ ■ 

uuxag; , and there is a possibility of 

increasing the load on the network. 

According to the RPR, normally in the case of 
transmitting the MAC frame from a certain node on the 
rxng to a different unspecified node, in a ringlet 
selection, the smaller in TTL is to be selected m 
a case where BJ-BD distances are equal in the network 
illustrated in FIG. 22, normally any one of the 
routes is predetermined. Herein, in the case of 
transmitting the frame on a route of SX-.bJ-.sA-. 
20 BD . SY, the bridge nodes BL, BC existing in the 

Middle Of the route can learn from the passing frame 
that the station SX is connected to the bridge node 
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25 



The bridge node, however, in the case of not 
yet learning that the station SY is connected to the 
bridge node BD , there being a possibility that 
station SY might be connected to the self-device (the 
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bridge node itself) , therefore copies the frame 
simultaneously when it passes through and transmits 
the frame to the off-the-ring network connected to 
the self -device. Moreover, the bridge nodes BF, BI 
through which the frame does not pass are unable to 
learn that the station SX is connected to the bridge 
node BJ. 

Supposing that there is a response on the 
higher-layer than the station SY, the frame is 
transmitted to the station SX and transferred across 
a route of SY ^ BD ^ SG BJ _ SX (because if the 
respective stations take the same algorithm, the 
equal distance implies a selection of the same 
direction) , in which case the bridge nodes BF, BI can 
learn that the station SY is connected to the bridge 
node BD. The bridge nodes BL, BC are, however, 
unable to learn. Further, the bridge nodes BF, BI do 
not yet learn that the station SX is connected to the 
bridge node Bj, and therefore send a copy of the 
frame to the network off the ring. 

When the frame arrives finally at the station 
SX from the station SY, the communications between 
the stations SX-SY via the outer route (the above 
route) become possible. However, the intermediate 
bridge nodes BL, BC, BF and BI cannot ever learn the 
address of the frame passing through the nodes 
themselves, resulting in a constant occurrence of the 



- 14 - 



10 



blooding (see FIG. 24: for example, Non-Patent 
document 8, slides 11 and 12). 

As a method of preventing the problem given 
above, there is a method of sending a response 
thereof in the frame-coming direction. For instance, 
the bridge node BJ starts transmitting round the 
outer ring to the station SY, and the bridge node BD 
also starts transmitting round the outer ring to the 
station SX . In the method, in a case where the 
respective stations SX , SY simultaneously transmit 
the frames to the destinations, the frames are passed 
round the outer ring and reach the destinations, 
while responses thereof are returned round via the 
inner ring to the destinations, and further responses 
thereof go round the outer ring and so on, resulting 
in an oscillating state where the destinations are 
floating. This induces a possibility in which the 
frame sequence might be reversed depending on a delay 
of frame transmission (refer to, e.g., Non-Patent 
document 8, slides 7 and 8). 

Further, as shown in FIG. 22, the 
communications between the stations SZ-SY involve 
using in principle a shorter route. Accordingly, the 
bidirectional communications via a route of SZ-BL-SA- 
25 BD-SY, are performed. Herein, if the communication 
line to BL -» SA is disconnected (cut off) , the 
communications round the^ outer ring in a direction of 
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SZ - SY cannot be carried out. Hence, the inner ring 
is used according to the steering. At this time, the 
respective bridge nodes BJ, BF , BI did not learn that 
the station SY is connected to the bridge BD . 
Accordingly, the flooding occurs. Besides, a 
response thereof is sent via a route of SY -* BD - SA 
- BL SZ round the inner ring as it used to be so 
far. This makes it impossible forever to learn f 
about the address mapping described just above (see 
FIG. 25: for instance, Non-Patent document 9, slides 
11 and 12) . 

As a method of preventing the aforementioned 
problem, there is a method of transmitting the 
response in the frame-coming direction in the same 
way as in the first problem. If a longer route 
between the bridge nodes BD-BL is selected, however, 
there are a larger number of cross-over nodes than by 
selecting the shorter. Accordingly, more of the 
whole usable bands are used up as a result. In other 
words, the load on the network rises. 

Thus, the transparent bridge system in the 
present situation has a possibility that an extra 
load increases in some cases . 

<2> For the reason of a reliability, etc., the 
frame addressed to the device on the off-the-ring 
network connected to the plurality of bridge nodes 
has no information about where to go and might be 
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lost. 

As shown in FIG. 29, it is considered from a 
point of view of the reliability that the off-the- 
ting station SY is connected to the two bridge nodes 
BC, BD on the ring. At this time, the selection of 
the connection between the station SY and the bridge 
nodes BC, BD , is determined by applying Spanning Tree 
Protocol defined in IEEE802.1D. Supposing that a 
route between BC-SY is selected, for instance, the 
frame is transmitted and received between the SX-SY 
via the bridge node BC , and each of the on-the-ring 
nodes learns that the station SY is connected to the 
bridge node BC (FIG. 26: normal state). 

Herein, if a failure occurs between BC-SY, the 
15 station SY selects a route between BD-SY in 

accordance with the Spanning Tree Protocol. The 
bridge node BC, however, simply judges that the 
communications with the station SY fall into a 
failure, and there is no method of knowing that the 
bridge node BD can surrogate. Hence, the frame sent 
addressed to the station SY is taken back by the 
bridge node BC, wherein the frame is judged to have 
the failure and discarded. Accordingly, all the 
frames from the station SX to the station SY do not 
reach in spite of an existence of the route of BD-SY 
(FIG. 27: failure state between BC-SY). This makes it 
meaningless to connect the station SY to both of the 
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bridges BC and BD in order to enhance the reliability 
(refer to, e.g., Non-Patent document 8, slides 9 and 
10) . 

As a plan for solving the problem, the 
IEEE802.17 Committee proposed that a flooding bit is 
provided in the RPR header. The processing is 
executed so that all the nodes on the ring can 
receive the frame in which the flooding bit is set 
irrespective of whatever destination it may have. 
FIG. 28 shows diagram of this concept. The plan 
enables the frame to reach the destination even in 
such a case as <2> by creating a method of flooding 
the frame to all the node at all times. Further, all 
of the node can always learn the same content. 
Accordingly, any problem as in <1> does not arise. 

The use of the communication bands of almost 
all the nodes for a certain frame, however, conduces 
to a loss of Spatial Reuse (a reuse of a space) that 
is greatly characteristic of the RPR. As a matter of 
fact, the system based on the plan described above 
comes to have substantially the same operation as the 
frame is transmitted and received in a case where the 
bridge device on the Ethernet actualized at the 
present is connected onto the ring. Therefore, a 
problem occurs afresh, wherein the meaning of 
utilizing the RPR is lost. 

These problems are derived from the RPR MAC 
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header destination address becoming none of the 
addresses of the nodes on the ring because of 
transmitting the frame transparently. In other words, 
the on-the-ring node that should receive (should do 
5 forwarding) cannot be designated uniquely by the MAC 
address, which becomes a factor for causing the 
respective problems as described above by the 
transparent bridge system. 

Such being the case, the IEEE802.17 Committee 

10 is examining a method of scheming to obviate the 

problems in such a form as to add an original EMAC 
address to the RMAC frame in the case of translating 
the EMAC frame into the RMAC frame. This is called 
an enhance bridge system. The following format plans 

15 are proposed for the system. 

(Plan-A) A system for transmitting and 
receiving by adding the MAC address to the RPR format 

FIG. 2 9 shows a format plan in which the MAC 
address is added. This plan-A is a method of 

20 invariably adding an address, as a destination, of 
the on-the-ring node to the Ethernet frame coming 
from outside the ring by the on-the-ring node. The 
plan-A is capable of obviating the problems. In 
order to make the off-the-ring MAC address 

25 corresponding to the on-the-ring MAC address, a 

transparent bridge learns which bridge node on the 
ring the station off the ring is connected to and 



sorts out it into a table format (e.g., Non-Patent 
document 9, slide 17). 

The plan-A has, however, the following defects. 
Namely, the plan-A has not compatibility with the RPR 
format used so far. Therefore, a device manufactured 
base don the plan-A is impossible of communicating 
with the existing device. This implies that an 
existing LSI for the RPR MAC layer processing that 
has been designed for the RPR device, cannot be used. 
Further, in the plan-A, al the nodes on the ring must 
execute the process (the process of adding the on- 
the-ring MAC address) . Hence, in the communications 
between the station nodes on the ring, the same 
address must be set in the RPR MAC address and in the 
MAC address. This kind of process is futile as far 
as the communications between the on-the-ring station 
nodes are concerned. Moreover, the format related to 
the plan-A has such an aspect that the overhead is 
always large and data communication efficiency is 
poor . 

(Plan-B) A plan for distinguishing by a flag as 
to whether the MAC address is added or not 

An addition of the MAC address is originally a 
piece of information needed only for the case where 
the bridge is related to the communications. 
Accordingly, there is considered a plan for adding 
the MAC address only in such a case that one (or 
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both) of the transmitting and receiving sides is the 
bridge node. This plan-B is shown in FIG. 30. a 
difference between the plan-A and the plan-B is given 
as follows. Namely, the plan-A is that the format is 
5 changed by adding the RPR MAC address at all times. 
By contrast, the plan-B is that the RPR MAC address 
is added only in a required case, and the 
communications are performed in the existing format 
other than this case. Accordingly, the addition of 
10 the RPR MAC address is not applied to the 

communications between the station nodes on the ring. 

The on-the-ring bridge node and station node, 
however, must distinguish between the addition and 
non-addition of the MAC address, depending on the 
communication partner. Therefore, the information 
(flag: 1 bit at the minimum) for judging whether the 
MAC address is added to the RPR header or not, is 
needed . 

The plan-B has the following defects. Namely 
the format to which the flag is added as in the plan- 
B has no cornpatibility with the original format as in 
the plan-A. Further, the plan-B must involve adding 
the flag to the RPR header afresh. Hence, there is 
no compatibility with the device manufactured based 
on the existing specifications, and the existing RPR 
MAC layer LSI can not be used. The plan-B. however 
unlike the plan-A, enables the communications with 
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the existing device with respect to the 
communications between the station nodes . Moreover 
in the plan-B, the RPR MAC address is not always 
added. Therefore, the overhead for a whole traffic 
is smaller than the plan-A. 

(Plan-C) A plan for encapsulating the whole 
frame in the bridge 

For giving the compatibility to the format, 
there is considered a method of encapsulating the 
whole MAC frame (EMAC frame) with the RPR MAC frame 
in the bridge. A format related to the plan-C is 
shown in FIG. 31 (for example, Non-Patent document 
slide 21, Non-Patent document 10, and slide 11). 

The plan-C has a necessity of registering 
afresh ET (Ethernet Type) for indicating 
encapsulation (an application to IETF is required) . 
It is not a problem to simply encapsulate the MAC 
frame in the plan-C. If this remains as it is, it 
follows that protocols ( IEEE802 . IQ-VLAN , MPLS, etc. 
for adding a label to between the header and the 
payload can not be supported (IEEE802.17 has a rule 
enabling these protocols to be supported. For 
processing on these protocols, new ETs are also 
required to be registered, and the ETs just 
corresponding to the number of protocols for 
processing are needed. 

In any plan among the plans A through C 
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explained above, in the case where the transmitting 
destination is the off-the-ring station subordinate 
to the bridge, when a mapping between the MAC address 
of the station and the MAC address of the on-the-ring 
bridge node is learned, the transmission becomes 
possible by adding the MAC address corresponding to a 
transmitting source and a destination on the ring. 

In the case of newly adding the station 
subordinate to the bridge, there is a case where a 
mapping relationship therebetween is not yet learned. 
In this case, it is required that the frame be sent 
to all the nodes (precisely to only the bridges 
therein) . Hence, a broadcast MAC address is added as 
a destination MAC address. The frame (the RPR frame) 
15 to which the broadcast MAC address is added, is 
received by each of the nodes. The bridge node 
receiving the RPR frame translates the RPR frame into 
an Ethernet frame and thus sends it to all the 
subordinate ports off the ring. If there is a device 
2 0 8a device having MACDA of the Ethernet frame) having 
the MAC address in any one of the off-the-ring ports, 
the device is capable of receiving a desired Ethernet 
frame. The station ruled out of the destination of 
the Ethernet frame receives the Ethernet frame, 
interprets its body frame and thereafter discards it. 

For actualizing the processes described above, 
in any plan among the plans A through C, the new 



25 
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format (or the encapsulated format) to which the MAC 
address is added must be interpreted by the node (see 
FIG. 32) . This implies that neither the plan-A nor 
the plan-B nor the plan C enables the device for 
5 processing only the existing format to be disposed 
within the ring (see FIG. 33) . 

For others, technologies described in the 
following Non-Patent documents 11 through 17 are 
given as the prior arts related to the invention of 

10 this application. 

[Patent document 1] Specification of U . S . P . 631 4110 
[Non-Patent document 1] IEEE Draft P802.17/D1.0 
(P802-17Dl-ob.pdf), chapters 5, 6, 8 and 10, Internet, 
<URL:http: //www . ntp . net . fujitsu . co . jp/StOrg/IEEE/> 

15 [Non-Patent document 2] Bridging Ad-Hoc (BAH) 
Overview (bah-upd-01 . pdf ) , Internet, 

<URL : http : //www . ieee802 .prg/17/documents/presentation 
s /may2 002 / index . htm> 

[Non-Patent document 3] Bridging on 802.17 LAN with 
20 802. ID/Q Compliance (bah-dotl-01.pdf), Internet, 

<URL: http: //www. ieee802.org/ 17 /documents/presentation 
s /may2 002 / index . htm> 

[Non-Patent document 4] Basic Bridging Compliance 
(bah-basic-03.pdf), Internet, 
25 <URL : http : //www . ieee802 . org/17/documents/presentation 
s/jul2002/ index. htm> 

[Non-Patent document 5] Enhanced Bridging Spatial 
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Reuse of 802.17 Bridge Traffic (bah-enhnc-02.pdf), 
Internet , 

<URL : http : //www . ieee802 . org/17/documents/presentation 
s/jul20 02 /index . htm> 
5 [Non-Patent document 6] IEEE802.17 Frame Structure 
and Bridging Ad-Hoc Support (bah-f rm-01 . pdf ) , Slides 

11, 17, 21, Internet, 

<URL:http: //www. ieee802 . org/17/documents/presentation 
s/may2002/index . htm> 
10 [Non-Patent document 7] Flooding in 802.17 Networks 
(bah-f ld-01 .pdf ) , Internet, 

<URL : : http : //www . ieee802 . org/17/documents/presentatio 
ns/may2 002 /index . htm> 

[Non-Patent document 8] 802 . ID/Q Compliance and 
15 Spatial Reuse (bah-spt-01 . pdf ) , Slides 7-8, 9-10, 11- 

12, Internet, 

<URL : http : //www . ieee802 . org/ 17 /documents /presentation 
s /may 2 002/ index / htm> 

[Non-Patent document 9] BAH 802.17 Frame Structure 
20 Requirements (bah-frame-02.pdf). Slide 11, Internet, 
<URL : http : //www . ieee802 . org/17/documents/prsentations 
/ju; 2002 /index .htm> 

[Non-Patent document 10] BAH Summary (bah-motion) , 
Internet , 

25 <URL : http : //www . ieee802 . org/ 17 /documents /presentation 
s/may2 0 02 /index . htm> 

[Non-Patent document 11] 802.17 presentations (bah- 
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fld-Ol.pdf), Internet, 

<URL : http : / /www . ieeeS 02 . org/ 1 7 /documents /presentation 
s/ jul2 002 /index. htm> 

[Non-Patent document 12] Bridging Ad-Hoc (BAH) 
5 Overview (bah-over-01.pdf), Internet, 

<URL : http//www . ieee802 . org/17/documents/presentations 
/jul2002 /index. htm> 

[Non-Patent document 13] 802.17 Bridging Compliance 
Roadmap (bah-road-01.pdf), Internet, 
10 <URL : http//www . ieee802 . org/17/documents/presentations 
/jul20 02 /index. htm> 

[Non-Patent document 14] TA Document IEEE802 . 17-11 
Jul2001/0.40:3, October 2001 (Basic-Bridging-Draf t- 
Text.pdf), Internet, 
15 <URL : http : //www . ieee802 . org/17/documents/presentation 
s/jul2002/index.htm> 

[Non-Patent document 15] Proposed DO . 3 Changes for 
Enhanced Bridging July 1, 2002 RESILIENT PACKET RING 

(RPR) (bridge-spat-draft02.pdf), Internet, 
20 <URL : http : //www . ieee802 . org/17/documents/presentation 
s/jul2002/index. htm> 

[Non-Patent document 16] IEEE Draft P802.17/D0.3 
Contribution, DRAFT STANDARD FOR (Flooding.pdf), 
Internet , 

25 <URL : http : //www . ieee802 . org/17/documents/presentation 
s/jul2 002/ index. htm> 

[Non-Patent document 17] IEEE Draft P802.17/D0.3 
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Contribution June 28, 2002, RESILIENT PACKET RING 
(RPR) (Formats.pdf), Internet, 

<URL:http: //www. ieee802 . org/17/documents/presentation 
s/ jul2 002 /index. htm> 

5 

SUMMARY OF THE INVENTION 

One of the objects of the invention is to 

provide, with respect to the problems described above, 

a technology related to a RPR network that eliminates 
10 a necessity for a distinguishing flag/ET indicating 

that a MAC address is added and a frame is 

encapsulated . 

Further, one of the objects of the invention is 

to provide a technology related to the RPR network in 
15 which a bridge node on a ring has means for receiving 

a frame with an unknown address. 

The invention adopts the following 

architectures in order to solve the problems 

described above. 
20 Namely, the invention is a RPR network system 

in a RPR network where a plurality of . station nodes 

terminating a MAC frame and a plurality of bridge 

nodes forwarding the MAC frame are connected to one 

or more rings, 

25 wherein each of the station nodes, in the case 

of transmitting the MAC frame to other station node, 
transmits a RPR MAC frame in which a MAC address of 



the other station node is set in a destination MAC 
address, and transmits, in the case of transmitting 
the MAC frame to a station off the ring that is 
connected an unspecified bridge node, a RPR MAC frame 
into which this MAC frame is encapsulated in such a 
state that the unspecified bridge node can capture it, 

each of the bridge node, in the case of 
receiving the MAC frame in which a MAC address of the 
off-the-ring station connected to other bridge node 
is set in a destination address from the off-the-ring 
station connected to the bridge node itself, 
transmits a RPR MAC frame into which the MAC frame is 
encapsulated in such a state that he other bridge 
node can capture it, and, in the case of receiving a 
MAC frame in which a MAC address of an unspecified 
station node is set in a destination MAC address from 
the off-the-ring station connected to the bridge node 
itself, transmits the MAC frame in a way that 
translates it into a RPR MAC frame, 

each of the station nodes captures the RPR MAC 
frame that is not encapsulated, and 

each of the bridge nodes captures the RPR MAC 
frame into which the MAC frame is encapsulated, and 
transmits the MAC frame within the captured RPR MAC 
frame to the off-the-ring station connected to the 
bridge node itself. 

In the invention, the MAC frame is, for example. 
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10 



an EMAC frame,, and the RPR frame is a RMAC frame. 

Further, the invention can be applied to a ring 
network configured of one or more rings, for instance, 
a RPR network configured of bidirectional dual rings 
examined by IEEE802.17, wherein station nodes and 
bridge nodes exist in mixture. 

The station node has a function of executing a 
process of terminating a MAC frame, i.e., a function 
of becoming a transmitting source and a transmitting 
destination. Further, the bridge node has a function 
of forwarding the MAC frame to a network on the same 
or a different protocol as or from the protocol 
possessed by the bridge node itself without 
terminating the MAC frame. 

Moreover, the station node, when transmitting 
the MAC frame to the station on the same ring, can be 
constructed to assemble a RPR MAC frame in a RPR MAC 
format defined in IEEE802.17 and to thus transmit it. 

Furthermore, the station node, when 
transmitting the MASC frame to the off-the-ring 
station connected to an edge of the bridges on the 
same ring, can be constructed to translate the MAC 
frame into a format suited to an off-the-ring 
protocol, then set it as a data field, further 
translate it into a format of its being encapsulated 
in the RPR MAC format, and transmit it to the bridge 
node on the ring. 



20 



25 
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Further, when the station off the ring 
transmits the MAC frame to the station node on the 
same ring via the bridge node on the ring, it can be 
constructed to transparently translate the MAC frame 
5 sent from the off-the-ring station into the RPR MAC 
frame in the bridge node on the ring and to transmit 
it to the on-the-ring station node. 

Moreover, when transmitting the MAC frame to 
the off-the-ring station connected to an edge of 

10 other bridge nodes on the same ring, it can be 

constructed to set the MAC frame sent from the off- 
the-ring station it as a data field in the on-the- 
ring bridge node, then translate it into a format of 
its being encapsulated in the RPR MAC format, and 

15 transmit it to other bridge node on the ring. 

This enables an architecture wherein the on- 
the-ring station node receives the MAC frame 
invariably in the RPR MAC frame format, the on-the- 
ring bridge receives invariably the RPR MAC frame 

20 into which the MAC frame based on the connection 
protocol with the off-the-ring station is 
encapsulated, and the bridge decapsulates it and 
performs forwarding of it to the station as an off- 
the-ring recipient . 

25 According to the invention, there is no 

necessity from the receiving side to judge whether 
the frame received by the on-the-ring station node 
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and bridge node is encapsulated or not. Namely, the 
station node and the bridge node, which correspond to 
the receiving sides of the RPR MAC frame, may not 
judge whether the MAC frame is encapsulated or not, 
5 Accordingly, the distinguishing flag and special ET 
explained in the prior art are not needed. A 
compatibility with the existing RPR nodes can be 
thereby maintained . 

It is preferable that the invention be 

10 constructed such that each of the station nodes and 

each of the bridge nodes have a table registered with 
the MAC addresses of all the station nodes and bridge 
nodes connected to the rings, ^ 

each of the station nodes, in the case of 

15 transmitting the MAC frame, transmits the MAC frame 

in a RPR MAC format if the destination MAC address of 
the MAC frame is registered in the table, and 
transmits the RPR MAC frame into which the MAC frame 
is encapsulated if the destination MAC address is not 

20 registered in the table, and 

each of the bridge nodes, in the case of 
forwarding the MAC frame received from the off-the- 
ring station connected to the bridge node itself, 
transmits the MAC frame in a way that translates the 

25 MAC frame into the RPR MAC frame if the destination 
MAC address of the MAC frame is registered in the 
table, and transmits the RPR MAC frame into which the 
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MAC frame is encapsulated if the destination MAC 
address is not registered in the table. 

As the table, there can be applied, for 
instance, a topology map table specified to be 
5 included according to RPR, registered with the MAC 
addresses of all the stations/bridges on the rings, 
distances/directions from the self-station/bridge. 

This being thus done, when the on-the-ring 
station node transmits the MAC frame and when the on- 

10 the-ring bridge node routes the MAC frame, if the 

destination MAC address thereof is registered in the 
table, the recipient is judged to be the on-the-ring 
station, whereas if not registered, the recipient is 
judged to be the off-the-ring station, and it is 

15 possible to determine whether the transmission object 
MAC frame is transmitted transparently as it is or 
the MAC frame is encapsulated. 

Moreover, it is preferable that the invention 
be constructed such that each of the station nodes 

20 and each of the bridge nodes have a mapping table 

stored with the MAC addresses of the bridge nodes and 
the . MAC addresses of the off-the-ring stations 
connected to the bridge nodes in a way that make them 
corresponding to each other, and 

25 each of the station nodes and each of the 

bridge nodes, in the case of transmitting the RPR MAC 
frame into which the MAC frame is encapsulated, set 
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the MAC address of the bridge node in a destination 
MAC address of the RPR MAC frame when the mapping 
table is stored with the bridge node MAC address 
corresponding to the destination MAC address of the 
5 MAC frame . 

Still further, it is preferable that the 
invention be constructed such that each of the 
station nodes and/or each of the bridge nodes retain 
a multicast address to a group which all the 

10 plurality of bridge nodes belong to, and 

each of the station nodes and each of the 
bridge nodes, in the case of transmitting the RPR MAC 
frame into which the MAC frame is encapsulated, set 
the multicast address in a destination MAC address of 

15 the RPR MAC frame when the mapping table is not 

stored with the bridge node MAC address corresponding 
to the destination MAC address of the MAC frame. 

Thus, the multicast MAC address to a group into 
which all the bridges on the ring are set, is 

20 registered, and the frame is transmitted to reach all 
the bridge nodes by setting the destination MAC 
address of the RPR MAC frame (into which the MAC 
frame is encapsulated) to the multicast address when 
unable to uniquely designate the destination MAC 

25 address of the RPR MAC frame. The encapsulated MAC 
frame can be thereby made to reach the of f -the-ring 
station as an edge to the bridge nodes . 
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Namely, it is feasible to provide means for 
allowing only the on-the-ring bridge node to receive 
the frame with its address unknown. 

Moreover, it is preferable that the invention 
5 be constructed such that each of the bridge nodes, in 
the case of transmitting the RPR MAC frame into which 
the MAC frame is encapsulated and in which the bridge 
node MAC address corresponding to the destination MAC 
address of the MAC frame is set in a destination MAC 
10 address, sets its own MAC address in a source MAC 
address of the RPR MAC frame, and 

the station node and/or the bridge node 
forwarding the RPR MAC frame into which the MAC 
address transmitted from the bridge node is 
15 encapsulated, stores the mapping table with a source 
MAC address of the RPR MAC frame and a source MAC 
address of the MAC frame within the RPR MAC frame in 
a way that makes them corresponding to each other. 

Further, the invention is a bridge node 
20 connected, together with a plurality of station nodes 
terminating a MAC frame, to one or more rings 
configuring a RPR network, 

wherein the bridge node, in the case of 
receiving the MAC frame in which a MAC address of 
25 other off-the-ring station connected to other bridge 
node connected to the ring is set in a destination 
MAC address, transmits a RPR MAC frame into which the 
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MAC frame is encapsulated in such a state that the 
other bridge node can capture it, and 

the bridge node, in the case of receiving the 
MAC frame in which a MAC address of an unspecified 
5 station node is set in a destination MAC address from 
the station, transmits the MAC frame in a way that 
translates the MAC frame into a RPR MAC frame. 

Still further, the invention is a station node 
connected, together with a plurality of bridge nodes 
10 forwarding a MAC frame, to one or more rings 
configuring a RPR network, 

wherein the station node, in the case of 
transmitting the MAC frame transmitted to other 
station not connected to the ring, transmits a RPR 
15 MAC frame in which a MAC address of the other station 
node is set in a destination MAC address, and 

the station node, in the case of transmitting 
the MAC frame to the of f -the-ring station connected 
to an unspecified bridge node, transmits the RPR MAC 
20 frame into which the MAC frame is encapsulated in 
such a state that the unspecified bridge node can 
capture it. 

Moreover, the invention is a RPR card installed 
into a bridge node connected, together with a 
25 plurality of station nodes terminating a MAC frame, 
to one or more rings configuring a RPR network, 

wherein the RPR card, in the case of receiving 



- 35 - 



the MAC frame transmitted from a station off the ring 
and in which a MAC address of other off-the-ring 
station connected to other bridge node is set in a 
destination MAC address, transmits a RPR MAC frame 
5 into which the MAC frame is encapsulated in such a 
state that the other bridge node can capture it, and 
the RPR card, in the case of receiving the MAC 
frame in which a MAC address of an unspecified 
station node is set in a destination MAC address from 

10 the station, transmits the MAC frame in a way that 
translates the MAC frame into a RPR MAC frame. 

Further, the invention is a MAC frame 
forwarding method for a bridge node connected, 
together with a plurality of station nodes 

15 terminating a MAC frame, to one or more rings 
configuring a RPR network, 

wherein the bridge node transmits, in the case 
of receiving the MAC frame transmitted from an off- 
the-ring station and in which a MAC address of the 

20 other off-the-ring station connected to other bridge 
node connected to the ring is set in a destination 
MAC address, a RPR MAC frame into which the MAC frame 
is encapsulated in such a state that the other bridge 
node can capture it, and 

25 the bridge node transmits, in the case of 

receiving the MAC frame from the station in which a 
MAC address of an unspecified station node is set in 
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a destination MAC address, the MAC frame in a way 
that translates the MAC frame into a RPR MAC frame. 

Furthermore, the invention is a MAC frame 
forwarding method for a RPR card installed into a 
5 bridge node connected, together with a plurality of 
station nodes terminating a MAC frame, to one or more 
rings configuring a RPR network, 

wherein the RPR card transmits, in the case of 
receiving the MAC frame transmitted from an off-the- 

10 ring station and in which a MAC address of the other 
off-the-ring station connected to other bridge node 
connected to the ring is set in a destination MAC 
address, a RPR MAC frame into which the MAC frame is 
encapsulated in such a state that the other bridge 

15 node can capture it, and 

the RPR card transmits, in the case of 
receiving the MAC frame from the station in which a 
MAC address of an unspecified station node is set in 
a destination MAC address, the MAC frame in a way 

20 that translates the MAC frame into a RPR MAC frame. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a diagram showing a format 
translation method according to the invention; 
25 FIG. 2 is an explanatory diagram of a frame 

transmission in a case where a mapping relationship 
of a MAC address is not yet learned; 
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FIG. 3 is a diagram showing an IP network model 
by way of an embodiment of the invention; 

FIG. 4 is an IP/MAC address table on each 
device (a RPR node) in the embodiment; 
5 FIG. 5 is a diagram showing an example of a 

topology map table retained on each RPR node shown in 
FIG. 3; 

FIG. 6 is an explanatory diagram of an ARP 
frame format between stations in the embodiment; 
10 FIG. 7 is an explanatory diagram of a format of 

an IP data packet (an IP frame) transferred and 
received between the stations in the embodiment; 

FIG. 8 is an explanatory diagram of a format of 
an ARP frame forwarded between a station node and the 
15 station; 

FIG. 9 is an explanatory diagram of a format of 
the IP data packet forwarded between the station node 
and the station; 

FIG. 10 is a diagram showing an example of a 
20 structure of a bridge node; 

FIG. 11 is a block diagram showing an example 
of a structure of a RPR card shown in FIG. 10; 

FIG. 12 is a diagram showing an example of a 
data structure of a learning table/MAC address 
25 mapping table; 

FIG. 13 is a flowchart showing a RPR MAC frame 
transmitting process by the station node; 
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FIG. 14 is a flowchart showing a RPR MAC frame 
transmitting process by the bridge node; 

FIG. 15 is a flowchart showing a RPR MAC frame 
receiving process by the bridge node ; 
5 FIG. 16 is a flowchart showing a RPR MAC frame 

receiving process by the station node ; 

FIG. 17 is an explanatory diagram of formats of 
the EMAC frame and the RMAC frame; 

FIG. 18 is a diagram showing an example of a 
10 RPR network; 

FIG. 19 is an explanatory diagram of assembling 
the RMAC frame; 

FIG. 20 is a table (Table 1) showing an example 
of a table (a topology map table) retained by the 
15 node on the ring; 

FIG. 21 is a table (Table 2) showing an example 
the topology map table of the node after a failure 
has occurred between the nodes on the ring; 

FIG. 22 is a diagram showing an example of the 
2 0 RPR network in which the station nodes and the bridge 
nodes exist in mixture; 

FIG. 23 is an explanatory diagram of a frame 
process executed by a transparent bridge pursuant to 
IEEE802 . ID; 

25 FIG. 24 is an explanatory diagram of flooding 

occurred ; 

FIG. 25 is an explanatory diagram of the 
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occurrence of the flooding when in a steering 
operation due to the failure; 

FIG. 2 6 is a diagram showing an example of the 
RPR network having the station connected to two 
5 bridges (a normal state) ; 

FIG. 27 is a diagram showing an example of the 
RPR network having the station connected to two 
bridges (a failure state between the bridge and the 
of f-the-ring station) ; 
10 FIG. 28 is a diagram showing plans of a method 

of solving a problem arising from the frame 
transmission to all the nodes on the rings; 

FIG. 29 is an explanatory diagram of a plan of 
adding the MAC address to the RPR format; 
15 FIG. 30 is an explanatory diagram of a plan of 

distinguishing an existence of the MAC address by 
attaching a flag to a RPR header; 

FIG. 31 is an explanatory diagram of a plan of 
encapsulating the MAC frame; 
20 FIG. 32 is an explanatory diagram of a process 

(a process in a case where the destination RPR MAC 
address is designated to be broadcast) in a case 
where a mapping MAC address is not registered in a 
translation table; and 
25 FIG. 33 is an explanatory diagram of a process 

(a process in the case where the destination RPR MAC 
address is designated to be broadcast) in a case 
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where the mapping MAC address is not registered in 
the translation table. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 
5 Embodiments of the invention will hereinafter 

be described with reference to the drawings. Note 
that constructions of the embodiments are an 
exemplification, and the invention is not limited to 
the constructions of the embodiments . 
10 [Outline of the Invention] 

To start with, an outline of the invention will 
be explained. FIG. 1 is a diagram showing a format 
translation method according to the invention, and 
FIG. 2 is an explanatory diagram of a frame 
15 transmission in a case where a mapping relationship 
of a MAC address is not yet learned. 

A format translation applied to the invention 
is shown in FIG. 1. This format translation is of 
the same encapsulation system as the C-plan given by 
20 way of the prior art. To be concrete, a MAC frame 
(EMAC frame) is encapsulated into a RMAC frame as 
follows. Namely, the whole EMAC frame is set as a 
payload (a user data field) of the RMAC frame; and a 
RPR header, a RPR MAC destination address (RPR MAC 
25 DA) , a RPR MAC source address (RPR MAC SA) , a ET 

(Ethernet Type) , a HEC (Header Error Check bit) and a 
FCS (Frame Check Sequence) , are added to the payload 



- 41 - 



as shown in FIG. 1, thereby assembling a RMAC frame. 

At this time, the MAC DA of the EMAC frame is 
translated into a RPR MAC address mapping thereto by 
use of a MAC address (EMAC address) -RPR MAG address 
5 translation table (retained on a RPR node that 

executes the encapsulation) , and this is set as a RPR 
MAC DA of the RMAC frame. Further, a MAC address (a 
self-node address), of the RPR node that executes the 
encapsulation is set as a RPR MAC SA of the RMAC 

10 frame. Moreover, the ET of the EMAC frame is copied 
and is set as an ET of the RMAC frame. Then, re- 
calculated values are set as a HEC and a FCS of the 
RMAC frame. The invention does not, however, unlike 
the C-plan, require registering a net ET (Ethernet 

15 Type) . 

Further, the invention is applied to a RPR ring 
(a RPR network) configured of a plurality of station 
nodes and a plurality of bridge nodes. A frame 
transmission process in the RPR network is 

20 substantially the same on the bridge node and on the 
station node. 

Concretely, it is judged whether a destination 
node (a node designated by the MAC DA) of a receipt 
frame is the station node or the bridge node, the 

25 encapsulation shown in FIG. 1 is effected in the case 
of the bridge node, and the transmission is executed 
without performing the encapsulation (through a 
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transparent translation (see FIG. 23)) in a case 
where it is not (but is the station node) . 

Through this, if the frame destination node is 
the bridge node, the receipt frame is invariably 
5 encapsulated and thus sent, and if the destination 
node is the station node, it is not invariably 
encapsulated and is thus sent. 

Accordingly, the station node, upon receiving 
the frame, executes a process for the non- 
10 encapsulated frame, and the bridge node may, upon 
receiving the frame, execute a process for the 
encapsulated frame. This eliminates a necessity of 
judging whether the Ethernet type based encapsulation 
has been done or not. Hence, a registration of a new 
15 Ethernet type becomes unnecessary. 

Furthermore, for actualizing the invention, the 
RPR node on the frame transmitting side is required 
to know whether the destination station is the 
station node on the ring or a station connected to 
20 the bridge node. Information for judging this is 
acquired from a topology map table as updated 
information about the respective RPR nodes on the 
ring, the map table being retained on each RPR node 
on the ring. 

25 Namely, each RPR node, on the occasion of 

transmitting the frame, searches as to whether or not 
the MAC address (MAC DA), of the destination node 
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exists in a MAC address group registered in the 
topology map table thereof, if it exists on the 
topology map table, the destination node is the 
station node on the ring, and hence its transmission 
5 is conducted without performing the encapsulation. 

If the destination node MAC address in the 
frame does not exist in the topology map table, it 
follows that there occurs a transmission to a station 
outside the ring that is connected to the bridge node, 

10 and hence it may be transmitted after being 
encapsulated . 

For effecting the encapsulation, it is the same 
as the plans A-C described in the prior art to create, 
learn and refer to a link mapping table (a 

15 translation table) for the MAC addresses of the 

bridge nodes on the ring and the MAC addresses of the 
stations subordinate thereto. 

Further, there is the case where the MAC 
address mapping relationship is not yet learned in 

20 the transmission of the frame. In this case, it is 
required that the frame be transmitted to all the 
bridge nodes on the ring. At this time, if a 
broadcast address is used as the destination node MAC 
address, the station nodes on the ring also become 

25 recipients. 

Such being the case, a multicast address is 
used for solving the problem. Namely, a multicast 
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address to one group into which all the bridge nodes 
on the ring are aggregated, is prepared and 
registered on each of the bridge nodes. Then, as 
shown in FIG. 2, in the case where the RPR MAC 
5 address corresponding to the destination node MAC 
address of the frame is not yet learned (in a case 
where the RPR MAC address mapping thereto is not yet 
registered in the table) , it is used for transmitting 
the frame to all the bridge nodes. 

10 If done in this way, only the bridge nodes on 

the ring can receive the frame. At this time also, 
the station node just lets the multicast frame pass 
through. Even if the station node executes a process 
of discarding the multicast frame, the station node 

15 can deal with also the encapsulated frame, and 
therefore any problem does not arise in the 
discarding process (see FIG. 2) . 

As described above, according to the invention, 
it is possible perform the communications between all 

20 the bridge nodes and station nodes on the RPR without 
adding any change to the packet format in the present 
rules, and also to provide the MAC bridging system 
having a small load in communications. 
[Embodiment] 

25 FIG. 3 is a diagram showing an IP network model 

by way of an embodiment of the invention. FIG. 4 is 
an IP/MAC address table on each device (the RPR node) 
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in the embodiment. FIG. 5 is a diagram showing an 
example of the topology map table retained on each 
RPR node shown in FIG. 3. 
<Outline> 

5 At first, an outline of the network system in 

the embodiment will be explained. In FIG. 3, devices 
RA, RB, BC, BD, RE, BF are RPR nodes, and the RPR 
nodes are constructed of station nodes RA, RB, RE 
having a function as a router, and of bridge nodes BC , 

10 BC, BF having a function as a bridge. These six 

pieces of RPR nodes configure one ring network. Each 
of these RPR nodes, through transferring and 
receiving a topology discovery packet, has already 
structured the topology map table shown in the table . 

15 in FIG. 5 inwardly of the device. 

S1-S6 shown in FIG. 3 are stations residing 
outside (off the ring) the RPRT network and capable 
of transmitting and receiving the IP frame. These 
stations S1-S6 have already acquired the IP addresses 

20 of all the devices including the RPR network. The 

respective device MAC addresses corresponding to the 
IP addresses are not yet learned. Further, each of 
the RPR nodes does not yet learn the MAC address of 
each station off the ring. 

25 Moreover, the all the nodes have already known 

the MAC address (MAC) to the group which the bridge 
nodes BC , BD , BF on the RPR network belong to, and 
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only the respective bridge bodes BC , BD, BF can 
execute a process of receiving this. 
<Operational Example> 

Next, an operational example of the network 
5 system in the embodiment will be described. In the 
network illustrated in FIG. 3, the operational 
example in data transmission/receipt (A) and (B) 
shown as below, will be explained. 

(A) Data Transmission to Station S6 from 
10 Station SI 

FIG. 6 is an explanatory diagram of an ARP 
frame format between stations SI and S6. FIG. 7 is 
an explanatory diagram of a format of an IP data 
packet transferred and received between the stations 
15 SI and S6 . 

In the case of transmitting the IP data frame 
to the station S6 from the station SI, to begin with, 
the station SI' is required to know the MAC address of 
the station S6 . Therefore, an ARP (Address 
20 Resolution Protocol) packet is sent to the network, 

and the MAC address of the station S6 is acquired. A 
frame format of the ARP packet is shown in FIG. 6. 

A destination address of the frame (the ARP 
frame: see FIG. 6A) transmitted from the station SI 
25 is broadcast (DA = BC) . Therefore, a transparent 
transmission according to the rules is conducted. 
Namely, the bridge node BC, which is connected to the 
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station SI and receives the ARP frame, sets a RPR 
header, a HEC and a recalculated FCS in the ARP frame, 
thereby translating the ARP frame (effecting a 
transparent translation) into a RPR-based format (see 
5 FIG. 6B) . 

Thereafter, the bridge node BC , the destination 
address of the ARP frame being the broadcast, the ARP 
frame is transmitted toward the RPR ring round an 
inner circle and an outer circle in both ways so that 

10 the ARP is received by all the nodes on the RPR. 

At this time, the bridge node BC , if not 
learning about the RPR node accommodating the station 
S6, sends the ARP frame having the format shown in 
FIG. 6A also to the station S2 . 

15 Further, the bridge node BC , with a trigger 

that the frame is received from. the station SI, 
learns that the station SI is connected as a 
subordinate to the self-device. Namely, the bridge 
node BC registers a mapping relationship between the 

20 MAC address (MSI) of the station SI and the MAC 

address (MBC) of the self-device (the bridge node BC) 
in the MAC address translation table. 

A destination address of the ARP frame (see FIG. 
6B) sent to the RPR network (the RPR ring) is the 

25 broadcast. Therefore, all the nodes on the ring 

receive it. At this time, each of the station nodes 
RA, RB, RE receives and analyzes the ARP frame. Each 
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of the station nodes RA, RB, RE, since a mapping IP 
address for obtaining the MAC address is different 
from a self IP address, does not respond to the ARP 
packet. 

5 By contrast with this, each of the bridge nodes 

BD , BF , upon receiving the ARP frame, because of the 
destination address (RPR MAC DA) being the broadcast 
(which means that it is not the MAC address of the 
bridge node) , judges that the ARP frame is not 
10 encapsulated. In this case, each of the bridge nodes 
BD , BF deassembles the ARP frame back to the original 
format (FIG. 6A) and thus transmits it to the 
subordinate station (it operates as being 
transparent) . 

15 Eventually, only the station S6 can respond to 

the ARP frame (for the reason that the mapping IP 
address set in the ARP frame is the IP address of the 
station S6) . The station S6, upon receiving the ARP 
frame, sends an ARP response frame mapping thereto in 

20 a format shown in FIG, 6C to the bridge node BF . 

The bridge node BF checks a destination node 
(destination) address (= MSI) of the ARP frame 
received from the station S6 and, this not existing 
in the topology map table (see FIG. 5), judges that 

25 the MAC address is a MAC address of a station off the 
ring. 

Further, the bridge node BF does not yet learn 
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about where the bridge node to which the station 
(that is herein the station S6) specified by the 
destination address is connected, is located. Hence, 
the bridge node BF assembles a RPR frame into which 
5 the ARP frame from the station SI is encapsulated in 
FIG. 6D by use of a multicast address (= MC) set for 
the bridge group, and sends it onto the RPR ring. A 
RPR destination address of the RPR frame is the 
multicast address. Therefore, the RPR frame is 

10 received only by each of the bridge nodes BC , BD on 
the RPR ring. 

Each of the bridge nodes BC, BD, the 
destination address of the RPR frame being the 
multicast address (the frame destination being the 

15 bridge node) , judges that the MAC frame (the EMAC 
frame) is encapsulated into the RPR frame, then 
decapsulates it to extract a body frame (the ARP 
frame) and sends it to the devices (the respective ^ 
stations off the ring) subordinate to the node itself. 

20 At this time, each of the bridge nodes BC, BD 

learns that the station S6 is connected subordinately 
to the bridge node BF . Namely, each of the bridge 
nodes BC, BD registers in the translation table a 
source address (SA = MBF) of the RPR frame and a 

25 source address (SA = MS6) of the MAC frame (the ARP 
frame) encapsulated into this in a way that makes 
them corresponding to each other. 
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Then, the ARP frame sent to the stations (which 
are herein the stations SI, S2 , S3, S4) off the ring, 
is received only by the station SI. Thus, the 
station SI can acquire the MAC address of the station 
5 S6 . 

Next, the station SI transmits an IP data 
packet (an IP frame) as an essential transmission 
object to the bridge node BC in a frame format shown 
in FIG. 7A. 

10 The bridge node BC receives the IP frame from 

the station SI and can, because of its destination 
address being the MAC address of the station S6 
(which is not registered in the topology map table) , 
recognize that the destination of the IP frame is not 

15 the node on the RPR ring but the station S6 

subordinate to the bridge node BF that has been 
already learned (already registered in the 
translation table) . 

Therefore, the bridge node BC assembles a RPR 

20 frame (see FIG. 7B) into which the IP frame from the 
station SI has been encapsulated with a RPR header 
designating the MAC address of the bridge node BF to 
a destination address, and sends it onto the RPR ring. 
Only the bridge node BF receives the RPR frame. 

25 The bridge node BF recognizes, as the destination is 
not designated to the broadcast, that the IP frame 
has been encapsulated. Accordingly, the bridge node 
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BF decapsulates it and transmits the body IP frame to 
the station S6. The transmission and the receipt of 
the data (the IP frame) between the station SI and 
the station S6 are thereby completed. 
5 Note that the bridge node BF , when receiving 

the RPR frame, can learn (can register in the 
translation table) from the its source MAC address 
and the source MAC address of the encapsulated MAC 
frame that the station SI is connected subordinately 

10 to the bridge node BC . Therefore, the frame 

transmission in a reversed direction, i.e., from the 
station S6 to the station SI can be done from this 
onwards in the same way as the IP frame has been sent 
to the station 86 from the station SI. 

15 (B) Data Transmission from Station Node RA to 

Station S3 

FIG. 8 is an explanatory diagram of an ARP 
frame format between a station node RA and the 
station S3. FIG. 9 is an explanatory diagram of a 

20 format of the IP data packet between the station node 
RA and the station S3. 

In the case of transmitting the frame to the 
station S3 from the router node RA, as in the case 
(A) , before the router node RA sends the IP frame to 

25 the station S3, there is required a procedure of 

knowing the MAC address of the station S3 trough the 
ARP packet. FIG. 8 shows a frame format related to a 
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RA-.S3 ARP. 

A destination MAC address of the ARP frame 
transmitted from the router node RA is a broadcast 
address (see FIG. 8A) . Therefore, each node on the 
5 ring can receive the ARP frame. At this time, each 
of the station nodes RB, RE receives and analyzes the 
ARP frame but does not respond to this because of not 
being its own IP address. 

On the other hand, each of the bridge nodes BC , 

10 BD, BF, when receiving the ARP frame, judges that 

this is not encapsulated, because the destination MAC 
address is the broadcast address, then performs the 
transparent translation and transmits it in a format 
shown in FIG. 8B to the subordinate station. 

15 Eventually, the station S3 receives the ARP 

frame. The station S3 sends to the bridge node BD an 
ARP response frame (having a format shown in FIG. 8C) 
to the ARP frame . 

The bridge node BD checks a destination MAC 

20 address of the ARP response frame. At this time, the 
destination MAC address is given such as ''DA = MRA" 
and is registered in the topology map table. Hence, 
the bridge node BD can recognize that the destination 
is addressed to the node on the ring. Therefore, the 

25 bridge node effects the transparent translation into 
the RPR forma without encapsulating and sends it (see 
FIG. BD) . 
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A destination f the RPR frame (the ARP response 
frame) is a station node RA. Accordingly, only the 
station node RA can receive the RPR frame 

From the RPR frame, the router node RA learns 
5 that the station S3 exists subordinately to the 

bridge BD , and completes an acquisition of the MAC 
address of the station S3. 

Next, the router node RA sends the IP data 
packet (the IP frame) as an essential transmission 
10 object to the station S3 as it is addressed thereto. 
Namely, the router node RA assembles a RPR frame (see 
FIG. 9A) into which the IP frame is encapsulated, and 
sends it. A destination MAC address of the RPR 
frame designates the bridge node BD (DA = MBD) . 
15 Therefore, the bridge node BD receives the RPR frame. 

The bridge node BD decapsulates the RPR frame 
arid transmits a body frame (the IP frame) to the 
station S3. The station S3 receives the IP frame 
from the bridge node BD . Thus, the transmission and 
20 receipt of the data (the IP frame) between the RA and 
S3 are completed. 

In a case where the station S3 sends the IP 
data packet (the IP frame) to the router node RA, the 
IP frame having the format shown in FIG. 9(b) is sent 
25 to the bridge node BD. 

The bridge node BD assembles the RPR frame (see 
FIG. 9C) into which the IP frame from the station S3 
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has been transparent-translated, and transmits it to 
the station node RA. The router node RA can thereby 
receive the IP frame from the station S3 . 

Two data transmission patterns in the network 
5 illustrated in FIG. 3 have been shown so far. As a 
matter of course, also between other stations, 
bridges and routers, if the frame is assembled based 
on the rule of the invention, the frame can be 
transmitted and received within the IP network by 
10 deassembling back to the original frame outside in 
accordance with the present specified format on the 
RPR. 

<Structure of Bridge Node> 

Next, an example of a structure of the bridge 
15 node will be explained, FIG. 10 is a diagram showing 
the example of the architecture of the bridge node, 
and FIG. 11 is a block diagram showing a structure of 
a RPR card shown in FIG. 10. FIG. 12 is a diagram 
showing an example of a. data structure of a learning 
2 0 table/MAC address mapping table. 

A bridge node 10 illustrated in FIG. 10 can be 
applied as each of the bridge nodes BC, BD, BF in FIG. 
3. The bridge node 10 includes an Ethernet card 
(Ethernet Card) 11 connected to the stations off the 
25 ring via an Ethernet circuit, a Giga Ethernet card 

(Giga Ethernet Card) 12 connected to the stations off 
the ring via a Giga Ethernet circuit, a RPR card (RPR 
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Card) 13 connected to the RPR ring, a switch (SW) 14, 
connected to the cards 11 through 13, for 
transferring and receiving the MAC frame between the 
cards by its switching operation, and a CPU card (CPU 
5 Card) 15 for controlling the cards 11 through 13 and 
the switch 14. 

Each of the RPR card 13, the Ethernet card 11 
and the Giga Ethernet card 12 is a card for 
processing the MAC frame at an Interface speed and on 

10 a protocol. The CPU card 15 performs a role of 

managing the cards 11 through 13 and controlling the 
switch 14 as an interface between the cards. 

Upon an input of the MAC frame to a certain 
card among the cards 11 through 13, the card searches 

15 through a learning table with the destination MAC 

address of the MAC frame being used as a key, and, if 
already learned, forwards it to other relevant card. 
At this time, if not learned, it floods the MAC frame 
to all other cards . 

20 Thus, the learning tables called ^^MACLEARN" 

exist in the respective cards 11 through 13, and are 
managed by the CPU card 15 to have the same learning 
content. 

Further, the individual cards 11 through 13 are 
25 managed based on port numbers, and the learning table 
retains the learning content (which is a mapping 
relationship between the port numbers and the MAC 
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addresses of the subordinate devices) in a form that 
shows which MAC address the device connected 
subordinately to the port number has . 

The RPR card 13 is a card for executing a 
5 protocol process according to the invention. As 

shown in FIG. 11, the RPR card 13 includes a switch 
interface (SW-INF) 21 connected to the switch 14 (FIG. 
10) , an L2 engine (L2 Engine) 22 connected to the 
switch interface 21, RPR MAC modules (constructed of 

10 LSIs) 23, 24 each connected to the L2 engine 22, and 
physical interfaces (PHY-INF) 25, 26 connected 
respectively to the RPR MAC modules 23, 24. 

Further, a topology map table 27, a learning 
table (MAClearn table) 28 and a MAC address mapping 

15 table 29 are connected to the L2 engine 22, and are 
referred to and/or updated depending on a process by 
the L2 engine 22. 

The RPR is of dual rings, and hence there are 
prepared the two physical interfaces 23, 24 

20 accommodating respectively outer and inner 

communication lines. The physical interface 25 
accommodates the outer line for receiving the frame 
and an inner line for transmitting the frame, while 
the physical inter face 26 accommodates the inner 

25 line for receiving the frame and the outer line for 
transmitting the f rame .- 

The L2 engine (L2_Engine) 23 executes processes 
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including the protocol process according to the 
invention. The L2 engine 23 selects one of the RPR 
MAC modules 23, 24 in accordance with the destination 
MAC address of the frame that should be forwarded to 
5 the RPR ring, and gives the frame to the selected RPR 
MAC module. It is thereby automatically determined 
which side (outer/inner: Outer/Inner) of the dual 
rings the frame is forwarded to. 

Each of the RPR MAC modules 23, 24 translates 
10 the MAC address into a final RPR format. Herein, the 
transparent translation and the encapsulation are 
carried out. 

Three categories of main tables exist in the L2 
engine 22. The first table is the topology map table 

15 27 necessary for the RPR protocol process. The 

topology map table 27 has the data structure shown in 
FIG. 5, and manages the MAC addresses, TTLs, etc. of 
the respective nodes on the ring. 

The second table is the learning table (MAC 

20 learning table) 28 that corresponds to the learning 

table explained in FIG. 10. The learning table 28 is 
registered with a mapping relationship between the 
port number retained the RPR card 10 and the MAC 
address of the device connected to a port having the 

25 port number. 

The third table is the MAC address mapping 
table 29 . The MAC address mapping table 29 is 
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registered with a mapping relationship between the 
MAC addresses of the stations subordinates to the 
node on the ring on the RPR side and the MAC 
addresses of the nodes themselves. The MAC address 
5 mapping table 29 corresponds to the translation table 
shown in FIG . 1 . 

The MAC learning table 28 can be merged with 
the MAC address mapping table 29. FIG. 12 is a 
diagram showing an example of a data structure of a 
10 table (MAC learn/MAC mapping table) 30 into which the 
table 28 and the table 29 are merged. 

As sown in FIG. 12, the table 30 can be 
registered per node on the ring by learning with 
records each consisting of a node name (a device 
15 name) , a MAC address of the node, a name (a device 
name) of the station off the ring that is connected 
to the node, a MAC address of the station and a port 
number corresponding to the station. 

The RPR card 13 shown in FIG. 11 is 
20 preinstalled also into each station node on the ring. 
<Processing Flow> 
Next, processes of the station off the RPR ring, 
the station on the RPR ring and the bridge node, will 
be explained. FIG. 13 is a flowchart showing a RPR 
25 MAC frame transmitting process by the station node, 
FIG. 14 is a flowchart showing a RPR MAC frame 
transmitting process by the bridge node, FIG. 15 is a 
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flowchart showing a RPR MAC frame receiving process 
by the bridge node, and FIG. 16 is a flowchart 
showing a RPR MAC frame receiving process by the 
station node . 

5 These processes are executed chiefly by the RPR 

cards preinstalled into the station nodes and the 
bridge nodes. The respective processes will 
hereinafter be described. 

<<Frame Transmitting Process by Station Node>> 

10 The station node, in the case of transmitting 

the IP data packet to a predetermined party (which is, 
e.g., an arbitrary station off the ring), executes 
the process shown in FIG. 3. 

At first, the station node searches for a MAC 

15 address corresponding to a destination node 

(destination) IP address (step SOI), and judges 
whether the MAC address is discovered (known) or not 
(step S02) . 

At this time, in case the MAC address is 

20 discovered (S02: Y) , the processing proceeds to step 
804. Whereas if not (S02: N) , the station node 
acquires the MAC address mapping thereto by the ARP 
packet transmitting process, and returns the 
processing to step 501. 

25 In step 804, the station node assembles a MAC 

frame (including the IP data packet) in which the 
discovered MAC address is set in a destination MAC 
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address . 

Next, the station node searches for a 
destination MAC address of the MAC frame by referring 
to the topology map table (see FIG. 5) (step SOS) , 
5 and judges whether or not the destination MAC address 
is discovered (registered in) from the topology map 
table (step S06) . 

At this time, in case the destination MAC 
address is discovered (S06: Y) , the transmitting 

10 destination is the station on the ring, and therefore 
the station node modifies the MAC frame into a RPR 
format (effects the transparent translation) , and 
forwards it onto the RPR ring (step S07) . Upon an 
end of step S07, the transmitting process is finished. 

15 While on the other hand, in case the 

destination MAC address is not discovered in step S06 
(S06: N) , the station node searches (Search) the 
MAClearn/MAC mapping table (retained on the station 
node) for the destination MAC address (step 808) , and 

20 judges whether the destination MAC address is 
discovered or not (step S09) . 

At this time, in case the destination MAC 
address is discovered (S09: Y) , the destination is 
the station off the ring that is subordinate to the 

25 bridge node, and the MAC address of the bridge node 
to which the station is connected, is known (which 
has already been registered in the MAClearn/MAC 
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mapping table) . Therefore, the station node acquires 
the MAC address of the bridge node that is set 
corresponding to the destination MAC address from the 
MAClearn/MAC mapping table (step SIO) . 
5 Subsequently, the station node encapsulates, in 

the RPR format, the MAC frame assembled in step S04, 
and transmits it (step Sll) . At this time, the 
station node sets the MAC address of the bridge node 
that has been obtained in step SIO as a destination 

10 MAC address in the RPR format. Upon finishing the 
process in step Sll, the transmitting process is 
terminated. 

In case the destination MAC address is not 
discovered in step S09 (S09; N) , the destination is a 

15 station off the ring that is subordinate to the 

bridge node, however, a state is that the MAC address 
of the bridge node to which the station is connected, 
is unknown (not yet registered in the MAClearn/MAC 
mapping table). Therefore, the station node 

2 0 encapsulates the MAC frame in a way that sets the 
multicast address to the bridge group as a 
destination MAC address in the RPR format, and sends 
it (step S12) . Upon finishing the process in step 
S12, the transmitting process is terminated. 

25 <<Frame Transmitting Process by Bridge Node>> 

Next, a frame transmitting process by each 
bridge node on the RPR ring will be explained. As 
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shown in FIG. 14, the bridge node 10 (FIG. 10) 
receives through the Ethernet card 11 or the Giga 
Ethernet card 12 the MAC frame (including, e.g., the 
IP data packet) from the station subordinate to the 
5 node 10 itself (SOOl) . The received MAC frame, in 

the case of its being sent to the RPR ring, forwarded 
to the RPR card 13 via the switch 14 (step S002) . 

Thereupon, in the RPR card 13, the L2 engine 22 
(FIG. 11) receives the MAC frame via the switch 

10 interface 21, and extracts a destination MAC address 
out of the MAC frame (step S003) . 

Next, the L2 engine 22 searches through the 
topology map table 27 as to whether the destination 
MAC address is registered therein or not (step S004) , 

15 and judges whether the destination MAC address is 
discovered or not (step S005) . 

At this time, in case the destination MAC 
address is discovered (S005; Y) , the transmitting 
destination is a station on the ring, and hence the 

20 L2 engine 22 gives the MAC frame to the corresponding 
RPR MAC module in accordance with the contents stored 
in the topology map table. The RPR MAC module, when 
receiving the MAC frame from the L2 engine 22, 
modifies the MAC frame into the RPR format (the 

25 transparent translation) . 

The translated MAC frame (a RMAC frame) is sent 
onto the RPR ring from the corresponding physical 
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interface (step S006) . Upon an end of step S006, the 
transmitting process is finished. 

While on the other hand, in step S005, in case 
the destination MAC address is not discovered (S005; 
5 N) , the L2 engine 22 searches the MAClearn/MAC 
mapping table 30 for the destination MAC address 
(step S007) , and judges whether the destination MAC 
address is discovered or not (step S008) . 

A this time, in case the destination MAC 

10 address is discovered (S008; Y) , the destination is a 
station off the ring that is subordinate to the 
bridge node, and the MAC address of the bridge node 
to which the station is connected, is known (which 
has already been registered in the MAClearn/MAC 

15 mapping table 30). Therefore, the Le engine 22 

acquires the MAC address of the bridge node that is 
set corresponding to the destination MAC address from 
the MAClearn/MAC mapping table 30 (step S009) . 

Subsequently, the L2 engine 22 forwards the MAC 

20 frame together with the MAC address obtained from the 
table 30 to the corresponding RPR MAC module in 
accordance with the contents in the topology map 
table 27. 

The RPR MAC module encapsulates, upon receiving 
25 the MAC frame and the MAC address from the L2 engine 
22, the MAC frame into the RMAC frame, and sets the 
MAC address in a destination MAC address of the RMAC 
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frame . 

Thereafter, the RMAC frame is sent onto the RPR 
ring via the corresponding physical interface (step 
SOlO) . Upon finishing step SOlO, the transmitting 
5 process is terminated. 

In step S008, in case the destination MAC 
address is not discovered (S008; N) , the destination 
is a station off the ring that is subordinate to the 
bridge node, however, a state is that the MAC address 

10 of the bridge node to which the station is connected, 
is unknown (not yet registered in the MAClearn/MAC 
mapping table 30) . Therefore, the L2 engine 22 
forwards the MAC frame and a multicast address 
(retained previously) to the bridge node group to the 

15 corresponding RPR MAC module in accordance with the 
contents of the topology map table . 

The RPR MAC module, upon receiving the MAC 
frame and the multicast address from the L2 engine, 
encapsulates the MAC frame into the RMAC frame and 

20 sets the multicast address in a destination MAC 

address of the RMAC frame. Thereafter, the RPR frame 
is sent onto the RPR ring via the corresponding 
physical interface (step SOU) . Upon finishing step 
soil, the transmitting process comes to an end. 

25 <<Frame Receiving Process by Bridge Node>> 

Next, a frame receiving process by the bridge 
node will be described. As shown in FIG. 15, the 
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bridge node 10 (FIG. 10) receives through the RPR 
card 13 the frame (RMAC frame) from the RPR ring. 

In the RPR card 13, a source MAC address (SA) 
of the RPR frame (the RMAC frame) is checked (step 
5 SlOl) , and it is judged whether the source MAC 

address is a self-device address or not (step S102) . 
At this time, in case the source MAC address is the 
self-device address (S102; Y) , the frame is discarded 
(step S103) , and the receiving process is finished. 
10 Whereas if the source MAC address is not the 

self-device address (S102; N) , a destination MAC 
address of the RPR frame (the RMAC frame) is checked 
(step S104) , and it is judged whether the destination 
MAC address is the self-device address or not (step 
15 S105) . 

At this time, in case the destination MAC 
address is the self-device address (S105; Y) , the 
processing proceeds to step S109, and in case it is 
not (S105; N) , the processing proceeds to step S106. 

20 In step S106, it is judged whether or not the 

destination MAC address is the multicast address to 
the bridge group, and the processing proceeds to step 
SllO in case it is the multicast address (S106; Y) 
and proceeds to step S107 in case it is not (S106; N) . 

25 In step S107, it is whether or not the 

destination MAC address is the multicast address to 
the bridge group, in case it is the broadcast address 
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(S107; Y) , the processing proceeds to step Sill, in 
case it is not (S107; N) , the RMAC frame is 
transmitted to a next device (neighboring node) (step 
S108) , and the receiving process is finished, 
5 In step S109, the RMAC frame is captured in the 

device (the bridge node) , and the processing proceeds 
to step S112. 

In step SllO, the RMAC frame is captured in the 
device (the bridge node) and also transmitted to the 

10 next device (the neighboring node) , and the 
processing proceeds to step S112. 

In step Sill, the RMAC frame is captured in the 
device (the bridge node) and also transmitted to the 
next device (the neighboring node) , and, assuming 

1.5 that the packet (the MAC frame) is not encapsulated, 
the processing proceeds to step S114. 

In a step 3112, it is judged whether a PT 
((packet type) (packet classification): see FIG. 17) 
in the RPR header of the RMAC frame is ''data packet 

20 (11)" or not. In case the packet type is the data 

packet, it is assumed that the packet (MAC frame) has 
been encapsulated into the RMAC frame, and the 
processing proceeds to step S113. 

In a step S113, the RMAC frame is decapsulated , 

25 the body frame (the MAC frame) is forwarded to the 
card (the Ethernet card of Giga Ethernet card) via 
the switch 14 in accordance with the destination MAC 
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address and further forwarded to the subordinate 
device (the station) from the card. Upon an end of 
step S113, the receiving process is finished. 

In step S114, the packet type (other than the 
5 data packet) in the RPR header of the RMAC frame is 
checked, and the packet (the user data field) in the 
RMAC frame is transferred to the protocol processing 
unit corresponding to the packet type. Upon 
finishing step S114, the receiving process is 

10 terminated. 

<<Frame Receiving Process by Station Node>> 
Next, a frame receiving process by the station 
node will be described. As shown in FIG. 16, when 
the station node receives the RPR frame (the RMAC 

15 frame) from the RPR ring, a source MAC address (SA) 
of the RMAC frame is checked (step S201) , and it is 
judged whether the source MAC address is a self- 
device address or not (step S202) . 

At this time, in case the source MAC address is 

20 the self-device address (S202; Y) , the frame is 

discarded (step S203) , and the receiving process is 
finished. By contrast with this, in case the source 
MAC address is not the self-device address (S202; N) , 
a destination MAC address of the RPR frame (RMAC 

25 frame) is checked (step S204) , and it is judged 
whether the destination MAC address is the self- 
device address or not (step S205) . 
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At this time, the processing proceeds to step 
S2 08 in case the destination MAC address is the self- 
device address (S205; Y) , and proceeds to step S206 
in case it is not (S205; N) . 

In step S206, it is judged whether the 
destination MAC address is a broadcast address or not, 
in case it is the broadcast address (S206; Y) , the 
processing proceeds to step S209, while in case it is 
not (S206; N) , the RMAC frame is sent to a next 
device (a neighboring node) (step S207) , and the 
receiving process is terminated. 

In step S208, the RMAC frame is captured in the 
device (the station node) , and the processing 
advances to step S210. 

In step S209, the RMAC frame is captured in the 
device (the station node) and transmitted to the next 
device (the neighboring node) , and the processing 
proceeds to step S210. 

In step S210, the packet type in the RPR header 
of the RMAC frame is checked, and the packet (the 
user data field) in the RMAC frame is transferred to 
the protocol processing unit corresponding to the 
packet type. Upon finishing step S210, the receiving 
process is terminated. 
25 [Others] 

The embodiment described above discloses the 
following inventions. The following inventions can 



15 



20 
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be properly combined. Note that the invention can be 
applied to a single ring in addition to the dual 
rings on which the RPR protocol functions . For 
example, one of the dual rings is so set as not to 
5 work due to a failure, and so on. Alternatively, on 
the occasion of forwarding the received MAC frame to 
any one of the rings, only one-side ring is 
invariably selected. Thus, the invention can be 
applied to the single ring. It is obvious that the 

10 kind of implementation can be easily embodied by 
those skilled in the art. 

According to the invention, it is possible to 
provide the RPR-network-related technology that 
eliminates the necessity for the flag for 

15 distinguishing and the ET indicating that the MAC 
address is added and the frame is encapsulated. 

Further, according to the invention, it is 
feasible to provide the RPR-network-related 
technology including means by which only the bridge 

20 node on the ring receives the frame with its address 
unknown. 



